Skip to content

build: warn when bin/hol or bin/unquote is older than its sources - #2037

Open
lukaszcz wants to merge 5 commits into
HOL-Theorem-Prover:developfrom
lukaszcz:build-check-stale-unquote
Open

build: warn when bin/hol or bin/unquote is older than its sources#2037
lukaszcz wants to merge 5 commits into
HOL-Theorem-Prover:developfrom
lukaszcz:build-check-stale-unquote

Conversation

@lukaszcz

@lukaszcz lukaszcz commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Problem

Several bin/ binaries are compiled by configure and by no Holmakefile rule, so pulling in a source change leaves them stale and silently wrong. build.sml guards this class of staleness with check_against, but its sweep only covers .sml files under tools/Holmake and tools-poly/Holmake, compared against bin/Holmake. Three gaps:

  • Under Moscow ML, bin/unquote runs as a pipe filter and mis-lexes new syntax when tools/parsing/HolLex changes. HolLex has no .sml extension and is not under a Holmake directory, so the sweep misses it.
  • Under Poly/ML nothing runs bin/unquote (emit_hol_unquote_script is a no-op); the filter is linked into bin/Holmake and bin/hol via hmcore.ML. So a stale unquote breaks nothing, while the binaries that do mis-lex go unchecked — and not just for HolLex: HOLSource* and AttributeSyntax in tools/parsing are baked in the same way.
  • Nothing checks bin/hol at all. tools-poly/hol.ML is swept by nothing, and a tree with a current bin/Holmake can still run a hol built from other sources. A stale hol misdirects the interactive load path and fails tools/Holmake/tests/repl, which -t reaches inside sequences/kernel — halting the selftest build.

Change

tools/build/build.sml (mosml): check bin/unquote against tools/parsing/HolLex.

tools-poly/build.sml (Poly/ML): check bin/hol against everything linked into it — tools-poly/hol.ML, the two Holmake sweeps, tools/parsing/HolLex explicitly, and an app_sml_files sweep of tools/parsing. No unquote check, which is not in the loop here. Checking hol covers Holmake's embedded filter too: configure builds Holmake first.

Both follow the existing check's shape — fire only if the executable is present, and warn ("you should reconfigure the system", Ctrl-C or RETURN) rather than fail.

Notes

  • Purely diagnostic; no behaviour change on an up-to-date tree.
  • An absent executable is skipped, not fatal, unlike the bin/Holmake check.

The quote filter's lexer is generated from tools/parsing/HolLex by
configure, and by no Holmakefile rule, so pulling a grammar change into
an existing tree leaves the old bin/unquote in place.  It then mis-lexes
the new syntax, and the failure surfaces a long way from its cause: a
lex error part way through some theory build, with nothing pointing at
the filter or at the need to reconfigure.

build already defends against this class of staleness -- check_against
on the configure scripts and on build itself, plus a sweep of every
.sml file under tools/Holmake against the Holmake binary -- but none of
those reach HolLex, which has no .sml extension and does not live under
tools/Holmake.  Check it explicitly, raising the same "this suggests
you should reconfigure the system" prompt as the existing guards, and
only when bin/unquote is actually present so that a tree which has not
been configured yet is unaffected.

Both build front ends get the check, tools/build for Moscow ML and
tools-poly for Poly/ML, each in the idiom the surrounding file already
uses for its filesystem calls.
bin/hol is compiled by configure from tools-poly/hol.ML and the Holmake
sources it links against, and by no Holmakefile rule, so pulling into an
existing tree leaves it stale with nothing to say so.  The guards already
in build do not reach it.  check_against covers the configure scripts,
build itself and Systeml.sig; the app_sml_files sweep covers tools/Holmake
and tools-poly/Holmake but compares them against bin/Holmake, so a tree
whose Holmake was regenerated can still run a hol built from quite
different sources.  hol.ML is covered by nothing at all.

This is not hypothetical.  1821cc3 moved the Meta.loadPath extension in
hol.ML from before loadState to after, because the state load restores
refs to their save-time values and was wiping it, and removed prelude.ML's
compensating re-extension in the same commit.  A tree carrying the old
bin/hol therefore got neither: loadPath stayed at the bare [sigobj], so
interactive load and open could not see INCLUDES directories, and the
banner prelude prints when the path grows never fired.  All six
tools/Holmake/tests/repl tests failed against their expected output.

That last part is what makes it expensive.  repl is a test-only entry in
sequences/kernel, so -t reaches it while still inside the kernel sequence,
and the failure aborts the build there.  Since build cleans and re-uploads
sigobj per entry, aborting that early strands every library from
src/marker onward, and per-directory Holmake in an affected directory then
fails with a name resolution error in unmodified source.  Nothing in that
symptom points at bin/hol, or at reconfiguring.

Poly only: under Moscow ML bin/hol is a shell script emitted by configure,
not a compiled artefact, so tools/build/build.sml has nothing to check.
@mn200

mn200 commented Aug 11, 2026

Copy link
Copy Markdown
Member

Poly/ML HOL does not run unquote (MoscowML does), though it's a nice tool to have around. Perhaps this test should be for out-of-date-ness against hol (which embodies the lexer in the REPL implementation code).

Under Poly/ML nothing runs bin/unquote: emit_hol_unquote_script is a
no-op there, and the filter's lexer and parser are instead linked into
bin/Holmake and bin/hol via hmcore.ML.  A stale bin/unquote therefore
breaks no build, while the binaries that do mis-lex a pulled grammar
change went unchecked -- and the exposure is wider than HolLex, since
the HOLSource* and AttributeSyntax sources in tools/parsing are baked
in the same way and swept by nothing.

So drop the unquote check from tools-poly/build.sml and instead check
tools/parsing against bin/hol in its existing check block: HolLex
explicitly (no .sml extension), the rest by app_sml_files sweep.
Checking hol alone covers Holmake's embedded copy too, because
configure builds Holmake before hol -- a bin/hol current with respect
to tools/parsing implies a bin/Holmake from the same run or a later
one.

tools/build/build.sml is unchanged: under Moscow ML unquote genuinely
runs as a pipe filter, so its check stands.
The comment's opening "likewise" pointed at the bin/unquote check
block deleted in the previous commit, and the tools/parsing rationale
trailed as a separate paragraph.  Fold both into one self-contained
block.
@lukaszcz lukaszcz changed the title build: warn when bin/unquote is older than tools/parsing/HolLex build: warn when bin/hol or bin/unquote is older than its sources Aug 17, 2026
@lukaszcz

Copy link
Copy Markdown
Contributor Author

Poly/ML HOL does not run unquote (MoscowML does), though it's a nice tool to have around. Perhaps this test should be for out-of-date-ness against hol (which embodies the lexer in the REPL implementation code).

Now for Poly/ML it checks bin/hol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants